[CoreCLR] support for debug build typemaps - #10065
Merged
Merged
Conversation
grendello
force-pushed
the
dev/grendel/clr-host-debug
branch
2 times, most recently
from
April 24, 2025 09:11
5aa8595 to
ccbe9f3
Compare
grendello
marked this pull request as ready for review
April 24, 2025 09:20
grendello
requested review from
dellis1972,
jonathanpeppers and
jonpryor
as code owners
April 24, 2025 09:20
grendello
force-pushed
the
dev/grendel/clr-host-debug
branch
2 times, most recently
from
April 25, 2025 13:58
8affdc3 to
73ad942
Compare
grendello
force-pushed
the
dev/grendel/clr-host-debug
branch
from
April 28, 2025 07:42
73ad942 to
76d4c89
Compare
Contributor
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
grendello
force-pushed
the
dev/grendel/clr-host-debug
branch
from
April 29, 2025 06:58
76d4c89 to
f948708
Compare
grendello
force-pushed
the
dev/grendel/clr-host-debug
branch
from
April 30, 2025 16:09
f948708 to
ae494c5
Compare
grendello
marked this pull request as draft
May 5, 2025 10:52
grendello
force-pushed
the
dev/grendel/clr-host-debug
branch
from
May 5, 2025 11:12
ae494c5 to
eff8a41
Compare
grendello
marked this pull request as ready for review
May 5, 2025 11:20
Contributor
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Lookup is done in managed, because type name is passed without assembly name. Need to change format of the generated debug maps.
grendello
force-pushed
the
dev/grendel/clr-host-debug
branch
from
May 12, 2025 07:43
6226b1d to
c038e2f
Compare
Contributor
[CoreCLR] support for debug build typemaps (#10065)
Context: 684ede6a79da5b95eb9347c319683d8855f84d09
Context: b11471bc574876e148ff40757c5d273fd6fbde9e
Context: 7117414ca27d88a71b4a272705a0207f772423bd
Context: c227042b6e58565e21dcd5e4ff5ea20fc4e9367c
Context: a0a837afb6b638030bd9d4f73ccad50ee88f89bf
Context: ea38c0c1219bf8807947a6b68c3c7efc93ce18ff
From b11471bc:
> `Java.Interop.JniRuntime.JniTypeManager` supports bi-directional
> mapping between JNI type signatures and managed `Type`s:
>
> * `GetTypeSignature(Type)` returns the JNI type signature that
> corresponds to the `System.Type`.
> * `GetType(JniTypeSignature)` returns the `Type` that corresponds
> to a JNI type signature.
We have had *multiple* ways to perform such mappings, including:
* Fully managed (Release config):
Processes trimmed assemblies, creates app-global mappings
within `Mono.Android.dll`.
Required for NativeAOT, optional with CoreCLR, MonoVM.
Commits 684ede6a, b11471bc
* MonoVM Instant Run (Debug config):
Per-assembly mapping data, fast deployed to to the target device.
Removed in commits 8298b6f7, 17e2e8ea.
* MonoVM libxamarin-app.so (Debug config):
Processes *un-trimmed* assemblies, creates app-global
*string-based* type mappings within LLVM-IR, so that mappings
don't need to be rebuilt as often when assemblies are changed.
Commits 7117414c, c227042b
* MonoVM libxamarin-app.so (Release config):
Processes trimmed assemblies, creates app-global
*assembly-based* type mappings within LLVM-IR, relying on
assembly name hashes, assembly MVIDs, and type token IDs.
Commits c227042b
* CoreCLR libxamarin-app.so (Release config):
Processes trimmed assemblies, creates app-global
*assembly-based* type mappings within LLVM-IR, relying on
assembly name hashes, assembly MVIDs, and type token IDs.
Commits a0a837af, ea38c0c121
"Missing" from this list is support for Debug config CoreCLR builds.
Begin implementing managed-to-Java lookups for Debug config CoreCLR
builds by
1. Updating `libxamarin-app.so` generation to emit data similar to
the "MonoVM libxamarin-app.so (Debug config)" data structures, &
2. Update `clr_typemap_managed_to_java()` /
`TypeMapper::typemap_managed_to_java()` within
`libmono-android.debug.so` to use the Debug config data in (1).
This allows (mostly) untrimmed assemblies to be used with typemap data.
Additionally, the managed-to-Java lookup tables use the
assembly-qualified managed type name; introduce a step to "fix up"
the passed managed type name by appending the assembly name, which is
obtained by searching for MVID match in the MVID-to-name lookup table. |
grendello
added a commit
that referenced
this pull request
May 19, 2025
Finish implementing java-to-managed typemap lookup for Debug builds (started in #10065). Maps translate Java type name to a pair consisting of the managed type's assembly name and its token ID within that assembly. This is then used by the managed land to find and load the indicated type. Optimize, by using hashes, the managed-to-java typemap lookup for Debug builds, with a fallback to string-based lookups if hash clashes are detected. Since it is hard to produce a test for such clashes, instead add a way to force usage of string-based lookups by checking whether the `CI_TYPEMAP_DEBUG_USE_STRINGS` environment variable is present and not empty in the environment. This is used in one of the tests. Additionally, optimize usage of certain sets of strings in native code, namely type and assembly names. Instead of storing them as "standard" string pointers, they are now contained in "blobs" - arrays of character data, separated with `NUL` characters. This approach gets rid of a potentially large number of native code relocations (each string is a pointer), replacing X pointers with a single pointer + offset when accessing a string. It also has a side effect of (slightly) reducing generated code size.
grendello
added a commit
that referenced
this pull request
May 20, 2025
Context: #10065 Context: #10075 This is the last of the PR series which implement support for `.NET for Android` applications Debug builds. While developing applications using Visual Studio, developers are in the cycle of making frequent changes and testing them on device or emulator. This development loop must be fast enough to not make the experience frustrating. One of the ways `.NET for Android` uses to make it better is the so-called "fastdev" mode in which the application APK is built and deployed without any assemblies in it, while the assemblies are synchronized individually to the device's filesystem, so they can be refreshed individually on changes affecting, thus saving time. The `.NET for Android` runtime must be able to locate those assemblies and load them from the filesystem, instead of using the usual assembly store included in the application package. This commit implements support for finding, enumerating and locating the fastdev assemblies on the filesystem. It also modifies one of the "install and run" unit tests to test the functionality.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements support for Debug configuration typemaps in CoreCLR apps.
This PR is limited to the managed-to-java lookup, as the java-to-managed one isn't
currently used in CoreCLR apps (that lookup is done in managed code, I will open a
new PR to experiment in this area).
This PR also doesn't implement support for fastdev, it will be addressed in a separate PR.
CoreCLR doesn't provide us with a way to translate a
System.Typeinstance to a type name innative code, and therefore the managed code calls into the native runtime to perform the lookup using the type name and the assembly MVID. However, the managed-to-java lookup tables use the assembly-qualified managed type name, so this PR introduces a step to "fix up" the
passed managed type name by appending the assembly name, which is obtained by searching for
MVID match in the MVID-to-name lookup table.